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PREFACE 
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conducted  by  the  Air  Force  to  develop  a Flexible  Intraconnect  for  tactical 
equipment  connectivity. 
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EXECUTIVE  SUMMARY 

V 

1.0  INTRODUCTION  - / 

This  Executive  Suamary^  highlights  the  key  eleaents  and  conclusions 
reached  during  Modular  C^  Interface  Analyses- per foraed^by  Martin  Marietta 
Corporation  from  October  1977  through  June  1979^^  a study  contract  or  the 
Rome  Air  Development  Center  (RAOC)c^to  define  a Flexible  Intraconnect  capabil-* 
ity  for  tactical  command,  control,  and  communications  (C3)  Systems. 

This  study  was  conducted  under  Project  2317,  "Tactical  Information 
cessing  and  Distribution”,  which  is  part  of  Program  Element  63789F  "Command, 
Control  and  Comauinications  (C3')  Advanced  Development."  The  study  is  refer- 
red to  as  the  "Flexible  Intraconnect",  which  more  aptly  descr^.bes  the  task  of 
intraconnecting  C3  equipments*. 

2.0  DEFINITION 


Flexible  Intraconnect  (FI)  is  defined  as  a common  transmission  capa- 
bility that  may  be  accessed  by  all  coomnini cat ions  and  automatic  data  pro^em- 
sing  devices  within  a tactical  air  force  command  and  control  center. -"^^e  Con- 
trol and  Reporting  Center  (CRC)  shown  in  Figure  1 is  a typical  center  with  a 
concentration  of  C3  equipments  deployed  in  a shelter-based  configuration  to 
support  air  operations. 
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3.0  OBJECTIVE 


The  objective  of  the  study  has  been  to  perfonri  analyses  as  necessary  to 
define  the  most  effective  design  concept  to  implemenc  an  FI  capabii^ity.  The 
developed  capability  for  C3  facilities  provider  operational  users  with  the 
flexibility  to  configure  for  current  and  future  requirements.  This  intra- 
connect would  become  the  foundation  of  Air  Force  progrrjis  concerned  with 
development  and  fielding  of  tactical  modular  C3  facilities.  Its  design 
emphasizes  modularity,  interoperability,  interconnectivity,  flexibility  and 
survivability.  The  design  supports  information  exchange  between  tactical  C3 
facilities  as  C3  equipments  and  employment  concepts  evolve  from  those  cur- 
rently used  to  those  which  may  exist  in  the  year  2000.  The  design  concept  is 
applicable  to  existing  systems  such  as  the  407L  Tactical  Air  Control  System. 
The  conceptual  design  is  compatible  with  the  architectures  of  the  Defense  Com- 
munication System  (DCS),  Worldwide  Military  Commmd  and  Control  System 
(WWMCCS),  Joint  tactical  Communications  Program  (TRI-TAC),  and  other  systems 
currently  under  development  such  as  the  Joint  Tactical  Information  Distri- 
bution System  (JTIDS)  and  485L  Tactical  Air  Control  System  Improvements 
(TACSI). 

The  design  is  capable  of  expansion  and  growth  to  accommodate  evolving 
concepts  such  as  computer  resource  sharing,  distrib>ited  data  bas e /management , 
packet  switching,  bus  concepts,  information  distribution,  radar  netting,  mod- 
ular operations  centers,  and  geographically  distributed  functions. 

The  proposed  design  meets  objectives  for  a wideband  Flexible  Intra- 
connect  for  Tactical  Air  Force  modular  C3  facilities  and  is  suitable  for 
deployment  either  in  a static  theater  environment  or  a tactical  deployment 
situation. 
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4.0  Background. 


Tactical  users  of  C3  centers  have  recognized  the  need  to  improve  the 
methods  for  interconnecting  equipment  in  these  facilities.  The  most  common 
problems  associated  with  the  curren**  intraconnect  methods,  using  multicon*- 
ductor  cable,  may  be  summarized  as: 

a.  Converting  incompatible  interface  characteristics  to  allov  com” 
patible  interoperation  between  dissim..^ar  devices 

b.  Inability  to  change  a center *8  configuration 

c.  Inability  to  upgrade  the  automatic  data  processing  (AD?)  system  by 
substitution  of  a single  device  such  as  the  CPU  without  reengine* 
ering  the  intraconnect  for  the  entire  ADP  system  and  replacement  of 
many  of  the  peripherals 

d.  Inability  to  permit  peripherals  at  remote  locations  to  access  the 
central  processing  unit  (CPU)  data  base 

e.  Excessive  setup  and  tear/doim  times 

f.  Weight  and  size  of  cable  harnesses 

g.  Security  vulnerability,  and 

h.  Low  reliability,  primal  ily  due  to  connector  failures. 

An  important  step  in  solving  these  problems  is  the  adoption  of  a common 
set  of  interface  characteristics  for  future  C3  systems.  It  is  also  important 
to  provide  compatible  interfaces  between  current  inventory  devices,  those  soon 
to  be  fielded,  and  those  to  be  developed.  Initially,  the  new  intraconnect 
will  accoomodate  a variety  of  interface  characteristics  by  providing  compati” 
bility  conversions  to  match  the  characteristics  of  the  common  standard. 
Specifications  for  future  C3  devices  could  easily  include  requirements  to  be 
compatable  with  FI  Input/Output  (I/O)  characteristics  in  accordance  with  the 
standard  interface. 


5.0  ANALYSES 


The  following  paregrephs  auRmarize  the  analysis  and  conceptual  design 
performed  on  the  study  of  the  FI. 

Task  I;  This  task's  efforts  were  directed  towards: 

a.  Defining  user  requireaents  for  the  Flexible  Intraconnect,  and 

b.  Selecting  a design  concept  for  iuplenentation  of  the  Flexible  Intra- 
connect. 

The  analysis  addressed  the  problem  of  information  transfer  within  a cen* 
ter,  i.e.,  within  each  shelter  and  among  the  shelters  that  constitute  the  cen- 
ter. Designer  investigations  were  performed  at  the  level  of  detail  necessary 
to  compare  the  coat  effectiveness  of  candidate  concepts. 

The  requirements  analyses  examined  the  time-phased  scenarios  of  C3 
equipment  the  Flexible  latraconnect  must  support,  and  provided  quantification 
of  traffic  flow  for  both  communications  and  Automatic  Data  Processing  (ADP) 
traffic  within  each  of  C.en  equipment  center  types.  Maximum  peak  traffic  load 
for  a Local  Intraconnect  within  a shelter  was  estimated  to  approach  130  Mega- 
bits per  second  (Mb/s).  Maximum  traffic  load  for  the  External  Intraconnect 
among  shelters  was  also  estimated  to  approach  130  Mb/s. 

The  recommended  FI  concept  provides  a two-level  intraconnect,  i.e.,  one 
level  for  local  (intrashelter)  traffic,  and  another  for  external  (intracenter) 
traffic.  The  Local  Intraconnect  employs  a conventional  open-loop  topology 
using  forty  twisted-pair  ribbon  cable  for  transmission.  Time  Division  Multi- 
plexing (TDM)  for  channelization,  and  sequential  polling  for  user  access. 

The  External  Intraconnect  employs  a st&r  topology  using  multichannel 
fiber  optic  cable  for  transmission,  TDN-SDM  for  channelization,  and  polling 
for  access  control. 

A three-phase  implementation  plan  was  described  that  would  allow  incre- 
mental development  of  the  intraconnec t , while  providing  intraconnect  capabil- 
ities compatible  with  the  requirements  of  the  incremental  evolution  cf  C3 
equipment. 

Task  II:  This  task's  efforts  were  directed  towards: 

a.  Analyzing  the  interface  characteristics  of  inventory  and  future  C3 
devices  that  interface  with  the  Flexible  Intraconnect 

b.  Ferforming  a functional  design  of  the  C3  device-to-Flexibie  Intra- 
connect interface 

c.  Preparing  a Preliminary  Interface  Standard  document  to  establish  a 
design  standard  for  the  C3  device-to-Flexible  Intraconnect  inter- 
face, and 

d.  Verifying  Che  capability  of  the  Flexible  Intraconnect  Concept  to 
satisfy  the  intraconnecr  requirements  of  the  revised  Tactical  Air 
Forces  Integrated  Information  System  (TAFIIS)  Master  Plan. 

The  interface  characteristics  of  all  communications  and  ADP  devices 
expected  to  access  the  intraconnect  were  compiled  and  analyzed  to  determine 
the  device-to-Local  Intraconnect  Unit  (LIU)  interface  requirements. 
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Existing  interface  standards  were  studied  to  determine  similarities  with  the 
requirements  identified  for  the  device-to-LIU  interface.  At  the  sne  time, 
analyses  were  performed  to  further  define  the  functional  operation  of  the  LIU, 
identify  the  characteristics  of  the  LlU-to-Local  Intraconnect  (LI)  interface, 
and  to  perform  a preliminary  functional  design  of  the  LIU  and  the  adapters. 
Outputs  of  these  subtasks  enabled  selection  of  characteristics  for  the  inter-- 
face  standard  to  be  applied  at  the  point  of  interface  between  the  LIU  and  thh 
ADP  or  communications  device.  A Preliminary  Interface  Standard  document  was 
prepared  to  describe  the  characteristics  of  the  recommended  interface. 

A concept  verification  effort  was  performed  confirming  that  the  recom* 
mended  Flexible  Intraconnect  concept  will  satisfy  the  intraconnect  require- 
meets  of  the  equipment  scenario  defined  ic  the  TAFIIS  Master  Plan. 

Task  III;  This  task's  efforts  were  dir^'cr  5.1  towards: 

a.  Preliminary  design  of  the  intraconnect  scheme  and  the  subnetwork  bus 
configurations 

b.  Communication  net%fork  impleLnentation 

c.  Development  of  message  structure,  protocols  and  formats 

d.  Network  control  and  resource  management 

e.  Security  aspects  relative  to  TEMPEST  effects,  intrusion,  and  eaves- 
dropping, and 

f.  Reliability,  Maintainability,  and  Availability  analyses. 

The  preliminary  design  study  details  operational  facets  of  the  FI  and 
shows  how  recommended  architecture  handles  point-to-point,  virtual  bus,  lasy 
Susan,  and  broadcast  messages. 

Control  functions  via  the  FI  Manager  were  examined  and  message  struc- 
ture, protocols,  and  header  formats  were  detailed.  The  interconnection  of  com- 
munication devices  and  their  interface  with  other  common-user  communications 
were  conceptually  designed.  Alternate  configurations  were  presented  to  time 
phase  cemmiuni cat  ions  into  the  FI. 

Incorporation  of  encryption/decryption  devices  into  the  FI  structure 
were  thoroughly  Investigated. 

A preliminary  reliibility,  maintainability  and  availability  analysis  was 
made  on  the  FI  system  to  determine  the  degree  of  redundancy  requirements  that 
must  be  incorporated  in  the  design  to  assure  operational  availability. 

A throughput  analysis  has  been  prepared  to  verify  system  response  time 
and  determine  probability  of  data  blockage. 


6.0  SUMMARY 


The  recoMiended  Flexible  InCreconnect  concept  eaployt  e tvo- level  but 
tranraittion  tysteui.  The  Local  Intraconnect  but  carriet  traffic  within  a 
thelter.  Figure  2 thovt  the  configuration  for  thit  concept  at  envitioned  for 
etiployment  in  C3  center*.  The  External  Intraconnect  but  carriet  traffic 
asong  theltert  of  a center.  Thit  but  contittt  of  multichannel  fiber  optic 
cablet  arranged  in  a ttar  topology  to  connect  each  equipment  thelter  with  a 
centrally  located  fiber  optic  trantponder  with  at  many  at  63  legt  in  the  ttar 
configuration.  Accett  to  the  External  Intraconnect  froca  a Local  Intraconnect 
it  tupervited  by  the  External  Intraconnect  Control  Unit  (EICU).  Functiont  for 
interfacing  between  the  External  and  Local  Intraconnectii  are  performed  in  the 
External  Intraconnect  Unit  (EIU). 


Figure  2.  Implementation  of  Recommended  Syttem. 


6.1  Local  Intraconnect 

Analytit  effort*  have  concentrated  on  detign  character iatict  of  the 
Local  Intraconnect;  the  point  of  interface  with  C3  devicea  and  the  appli- 
cation of  the  Interface  Standard.  Figure  3 thowt  the  open-loop  topology  of 
the  Local  Intraconnect.  The  local  Intraconnect  but  contittt  of  a forty 
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twisted-pair  ribbon  cable  looped  between  communication  and  ADP  devices  within 
a shelter.  Data  transfer  is  in  parallel  at  a 200  Mb/s  rate.  Devices  access 
the  Intraconnect  by  means  of  an  LIU.  The  device  side  of  the  LIU  will  be  de- 
signed to  meet  the  characteristics  of  the  Interface  Standard.  If  the  device 
Input/Ouput  (I/O)  interface  characteristics  are  compatible  with  this  Interface 
Standard,  the  device  may  be  connected  directly  to  the  LIU.  If  not,  the  neces- 
sary compatibility  conversions  are  performed  by  an  adapter  module.  LIU  access 
to  the  Local  Intraconnect  bus  is  controlled  by  the  Local  Intraconnect  Control 
Unit  (Lieu).  63  LIUs  can  be  serviced  on  the  Local  Intraconnect.  The  LICU 
polls  each  LIl’  to  coordinate  transmission  of  data  blocks  over  the  local  bus. 


Figure  3.  Local  Intraconnect. 


6.2  External  Intraconnect: 


The  External  Intraconnect  uses  a star  topology.  This  concept  provides 
an  efficient  means  of  transmitting  data  throughout  the  center.  Figure  4 shows 
the  External  Intraconnect  bus  configuration  for  a Control  and  Reporting  Center 
(CRC).  This  concept  was  selected  over  others  for  its  capacity,  compatability , 
flexibility,  security,  and  growth  characteristics.  Forty  wire  pairs  from  the 
Lieu  with  5 Mb/s  parallel  data  on  each  are  multiplexed  onto  four  fiber  optic 
wave  guides  in  the  EIU.  Each  wave  guide  handles  50  Mb/s  data.  The  EIU  thus 
performs  data  conversion  and  electrical^to-optical  transition.  Subsystems  may 
be  located  up  to  8 Km  from  the  transponder.  The  EIU  multiplex  structure  is 


Figure  4.  External  Intraconnect  Topology. 
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Figure  5.  External  Intraconnect  Unit  (EIU) 


The  propofed  External  Intraconnect » providing  coonunicationt  between 
shelters,  uses  fiber  optic  cables  as  the  transaission  means.  Fiber  optics 
wer^  selected  for  the  following  reasons: 

a.  Wide  bandwidth 

b.  Negligible  crosstalk 

c.  Mo  coonon^ode  or  ground-loop  problems 

d.  Cable  impervious  to  EMP  or  lightning  disruption 

e.  Fastest  service  restoration 

f.  High  link  availability 

g.  Smallest  size,  lowest  weight  of  all  candidates,  and 

h.  Lowest  cost  alternative  now,  with  further  cost  reductions  in 
prospect. 

The  External  Intraconnect  will  intraconnect  a maximum  of  63  LlCUs. 


6.3  Data  Transfer  Protocols. 


Considerable  work  has  been  done  on  the  development  of  data  transfer 
protocols.  Protocols  to  control  data  transmission  over  the  FI  have  been  def- 
ined for  all  levels  of  communication.  The  overall  view  of  data  transmission 
control  can  be  seen  in  Figure  6.  The  characteristics  of  data  transmission  on 
the  FI  can  be  described  in  both  functional  and  operational  terms.  Figures  7 
and  8 show  the  five  different  layers  of  protocol  affecting  data  flow  over  the 
FI. 

a.  FI  Level  A concerns  user-to-user  protocol,  i.e.,  process  control. 
This  data  transfer  control  governs  activities  between  devices  as  if 
they  were  directly  connected. 

b.  FI  Level  B pertains  to  the  formatting  of  address,  control,  and  data 
to  and  from  a DTE  for  interface  to  other  DTEs.  This  protocol  is 
mainly  for  control  between  adapters  and  would  disappear  when  adapt- 
ers are  no  longer  needed. 

The  following  three  layers  of  protocol  combine  to  perform  end-to-end 
data  transmission  between  users  on  the  FI.  They  are  unique  to  the  FI. 

c.  FI  Level  C concerns  the  data  link  between  a DTE  or  SAU  and  the  FI. 
Control  information  for  operation  on  the  FI  is  contained  in  a device 
header  which  is  attached  to  a block  of  data  by  the  DTE  or  SAU. 

d.  FI  Level  D consists  of  the  LI  control.  A network  header  and  trailer 
are  added  to  the  device  header  and  data  block  by  the  LIU.  This  pro- 
vides information  required  to  control  LIU-LIU  and  LIU-LICU  data 
transfers . 

e.  Data  transfer  on  the  El  continues  using  the  network  header  and 
trailer  formulated  at  FI  Level  D.  However,  communication  between 
the  EICU  and  EIUs  is  required  to  configure  the  FI  into  a proper  mode 
of  operation.  This  warrants  a separate  layer  of  protocol  - FI  Level 
E - which  pertains  to  the  El  control. 

FI  Levels  D and  £ are  transparent  to  the  user. 
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Figure  7.  Levels  of  Protocol. 


FI  Level  B 


FI  Level  D 


Fi  Level  B 


FI  Level  A 


FI  Level  C 


FI  Level  E 


FI  Level  C 


FI  Level  A 


Figure  8.  Fonsats  at  each  FI  Level. 
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6.4  Data  Transfer  Scenario 


The  following  scenario  describes  data  transfer  from  DTE-1  to  DTE-2.  The 
referenced  DTE-1,  DTE-2,  DTE-5,  etc,  are  shown  in  Figure  9.  The  functional 
flow  is  depicted  in  Figure  10. 


Figure  9.  Flexible  Intraconnect  Exasple. 

A DTE-1  wishing  to  transnit  data  on  the  FI  attaches  a device  header  to 
the  block  of  data.  This  header  provides  control  information  required  for 
DTE-DTE  operation.  The  transfer  of  this  header  and  data  between  the  DTE  and 
LIU  is  accomplished  according  to  the  interface  standard.  For  present-day 
DTEs,  a Special  Adapter  Unit  (SAU)  may  be  required  for  interface  to  the  LIU. 
The  DTE  would  transmit  the  data  to  the  SAU  as  if  directly  connected  to  the 
destination  DTE,  (in  this  case,  DTE2  or  DTES).  The  adapter,  in  turn,  would 
structure  this  data  for  transmission  to  the  LIU  in  accordance  with  the  inter- 
face standard. 

The  header  is  transmitted  to  the  LIU  in  DMA  fashion  with  the  block 
length  always  equal  to  sixteen  18-bit  words.  Transfer  of  the  data  field  to 
the  LIU  is  deferred  until  the  LIU  extracts  the  word  count  to  determine  the 
block  length  of  the  data,  checks  if  the  virtual  address  is  valid,  and  tests 
the  header  for  parity  errors. 
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Figure  10.  Data  Transfer  Functional  Flow. 


If  an  error  is  detected,  the  LIU  fomulates  error  message  to  be 
trinsmittsd  to  the  FI  Manager.  If  no  error  is  detected,  the  rest  of  the  mes- 
sage block,  i.e.,  the  data  field,  is  transferred  from  the  DTE  to  the  LIU  in 
DMA  fashion.  Three  events  must  occur  at  the  end  of  the  data  transfer:  1)  the 
proper  sign-off  procedure  as  described  in  the  interface  standard  takes  place 
between  the  LIU  and  DTE/SAU;  2)  the  Input  Data  Request  (IDR)  line  goes  to  in- 
active; and  3)  the  number  of  data  words  transferred  compares  to  the  message 
word  count  which  was  previously  extracted  from  the  device  header.  If  an  error 
is  found  in  any  of  these  events,  an  error  message  is  formulated  and  sent  to 
the  FI  Manager.  If  no  error  is  detected,  the  LIU  modifies  the  device  header 
and  header  parity  bit  to  each  8* bit  byte,  adding  a date-time  group,  and  chang* 
ing  the  vertical  parity  to  reflect  these  additions.  The  LIU  also  generates  an 
FI  network  header  for  control  of  data  transmission  between  FI  components, 
e.g.,  LIU,  Lieu. 

6.4.1  Local  Intraconnect.  The  data  packet  is  held  by  the  transmitting 
LIU  (LIU-1)  until  a poll  is  received  from  the  LlCU  (LICU-1)  which  is  contin- 
ually polling  all  devices  on  its  bus.  The  poll  message  sent  from  the  LlCU  is 
stored  in  a buffer  in  each  LIU  until  an  accept/reject  decision  is  made  by  the 
LIU,  i.e.,  the  LIU  decides  if  the  message  is  intended  for  it. 

After  accepting  the  poll  message  from  the  LlCU,  the  LIU  must  respond 
with  a message  indicating  if  it  has  data  ready  for  transmission.  If  not,  the 
LlCU  continues  to  poll  the  other  LlUs  on  its  bus.  The  LIUs  response  to  the 
poll  depends  on  the  type  of  message  it  is  transmitting.  If  the  message  is  a 
broadcast,  a laxy  susan,  or  for  a virtual  bus,  the  entire  data  block  is  trans- 
mitted on  the  LI  by  LlU-l.  Any  other  message  type  requires  a query  from  LIU- I 
as  to  the  availability  of  buffer  space  large  enough  to  hold  the  data  packet  at 
the  immediate  destination  (LIU  for  local  traffic  or  LlCU  for 
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external).  As  shown  in  Figure  11,  if  the  buffer  is  not  available,  the  destin-* 
ation  stores  LIU- Is  address  in  a queue  (if  not  previously  stored),  then  noti- 
fies LIU-1  of  the  buffer  nonavailability.  The  purpose  of  storing  the  source's 
address  is  to  assure  th4\t  later-polled  LIUs  will  not  gain  access  to  the  s&iae 
destination  before  LIU-i.  Buffer  space  will  be  allocated  by  the  destination 
to  LIU-1  according  to  its  position  in  the  stack.  Meanwhile,  the  LICU  will 
continue  polling  to  expedite  traffic  on  the  bus.  LIU-1  will  transait  data  to 
the  destination  LIU  or  LICU  once  it  receives  i poll  after  destination  buffer 
space  becomes  available. 


Figure  U.  Buffer  Availability  Determination 

If  the  destination  is  a DTE  on  the  same  bus  (in  this  case,  DTC-2),  its 
associated  LIU  will  store  the  message  in  one  of  its  buffers.  This  LIU  (LIU-2) 
will  then  check  the  network  header  for  parity  errors  - vertical  and  horisontal 
- and  verify  the  number  of  header  words.  Error  checking  will  also  be  done  on 
the  data  portion  of  the  message  block.  If  an  error  is  detected  in  the  network 
header,  an  error  message  is  formulated  by  LlU-2  to  be  sent  to  the  FI  Manager. 
Error  checking  will  also  be  done  on  the  rest  of  the  message  block  (device 
header  and  data).  If  an  error  is  detected  here,  LIU-2  will  formulate  a 
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message  notifying  DTE-2  of  the  error.  If  the  transmission  is  error-'free, 

LIU'*2  will  extract  the  message  length  from  the  device  header  to  set  up  the  DMA 
transfer  of  the  data  to  DTE-2.  The  device  header  and  data  is  transmitted  to 
DTE-2  in  a DMA  fashion  according  to  the  standard  interface. 

6.4.2  External  Intraconnect.  If  the  destination  is  a DTE  on  a differ- 
ent LI,  such  as  in  a separate  shelter  (in  this  case,  DTE-5)^  LICU-1  will  hold 
the  message  block  until  a buffer  is  available  in  EIU-1.  LICU-1  then  transfers 
the  data  to  EIU-1  in  DMA  fashion  according  to  the  interface  standard.  EIU-1 
will  hold  the  message  packet  until  it  is  polled  by  the  EXCU.  The  response  by 
EIU-1  to  the  poll  depends  on  the  type  of  message  it  is  transmitting.  If  the 
message  is  broadcast,  lazy  susan,  or  for  a virtual  bus,  the  entire  data  packet 
is  transmitted  on  the  FI  by  EIU-1.  All  other  message  types  require  a query 
from  EIU-1  as  to  the  availability  of  buffer  space  large  enough  to  hold  the 
data  at  the  destination  EIU  (EIU-3).  If  buffer  space  is  unavailable,  EIU-5 
stores  SIU-ls  address  in  a queue  (unless  previously  stored),  then  notifies 
EIU-1  of  the  buffer  nonavailability.  As  in  the  case  of  the  LlUs,  EIU-1  will 
be  allocated  buffer  space  in  EIU-5  according  to  its  position  in  the  queue. 

The  EICU  will  continue  to  poll  the  other  EIUs  in  the  network.  EIU-1  will 
transmit  data  to  EIU-5  upon  receiving  a poll  after  buffer  space  (in  EIU-5) 
becomes  available.  Upon  acceptance  of  the  message,  EIU-5  will  transmit  the 
data  packet  to  LICU-5  when  buffer  space  becomes  available  in  LICU-5.  The  data 
is  transferred  from  EIU-5  to  LICU-5  in  DMA  fashion  according  to  the  interface 
standardv  LICU-5  will  then  transmit  the  message  block  (if  broadcast,  lazy 
Susan,  or  for  a virtual  bus)  or  a query  as  to  the  availability  of  buffer  space 
in  the  destination  LIU  (LIU-5).  Buffer  nonavailability  is  treated  as  pre- 
viously described  - queuing  of  LlCU-5s  address  in  LIU-5,  notification  to 
LICU-5,  and  waiting  for  buffer  availability  before  transmission  of  the  message 
from  LlCU-5  to  LIU-5.  Upon  acceptance  of  the  data  packet,  LIU-5  checks  for 
transmission  errors  as  previously  described  for  LIU-2.  Again,  if  an  error  is 
found,  an  error  message  is  formulated  by  LIU-5  and  sent  to  the  FI  Manager 
and/or  DTE-5.  Otherwise,  LIU-5  will  set  up  the  DMA  transfer  mode  to  DTE-5  and 
transmit  the  device  header  and  data  according  to  the  interface  standard. 

7.0  FI  SYSTEM  DETAILS 


Complete  details  of  the  FI  system  design  and  its  rationale  may  be  found 
in  Martin  Marietta  report  MCR-79-14U,  Volumes  T and  II. 

These  volumes  describe  in  detail  all  work  performed  in  Tasks  1,  2,  and  3 
of  Air  Force  contract  FI 9623-77-C-0262. 
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